home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960209-19960425 / 000347_news@columbia.edu _Sat Apr 6 12:34:16 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id MAA00897 for <kermit.misc@watsun>; Sat, 6 Apr 1996 12:34:16 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id MAA06227 for kermit.misc@watsun; Sat, 6 Apr 1996 12:34:13 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: I can receive files but sending fails
  8. Date: 6 Apr 1996 17:33:54 GMT
  9. Organization: Columbia University
  10. Lines: 25
  11. Distribution: us
  12. Message-ID: <4k69u2$62b@apakabar.cc.columbia.edu>
  13. References: <4k44po$sf@abyss.West.Sun.COM>
  14. NNTP-Posting-Host: watsun.cc.columbia.edu
  15.  
  16. In article <4k44po$sf@abyss.West.Sun.COM>,
  17. John Chandler [Contractor] <johnch@West.Sun.COM> wrote:
  18. : 
  19. : Using kermit on my machine at home (486 running Solaris 2.4), I can 
  20. : download files from my internet service provider, either text or 
  21. : binary, but when I attempt to send a file, text or binary, I get 
  22. : either a string of "T%" or %N" characters.  I have only tried this 
  23. : in server mode.  Does someone have a clue what might be going on, 
  24. : or what parameters I should try altering?  
  25. : 
  26. : The procedure I am using is one that has worked for me between other
  27. : pairs of machines.
  28. : 
  29. This is not sufficient information to provide a useful answer.
  30. Entire books have been written on the topic :-).  I'd suggest you look
  31. at one of them.  Chapter 6 of "Using C-Kermit", "Solving File Transfer
  32. Problems", is recommended.
  33.  
  34. Briefly -- when file transfer works in one direction but not the other,
  35. this usually indicates a buffering or flow control problem in the failing
  36. direction, or a lack of transparency to the 8th bit (if you are transferring
  37. 8-bit data), or a lack of transparency to certain control characters (which
  38. would affect you only if you were using the "set control unprefix" feature).
  39.  
  40. - Frank